System and method for providing a user interface for managing calls received at a mobile device

ABSTRACT

Embodiments of a system and method for providing a user interface for managing calls received at a mobile device is described. The user interface provides an incoming call screen to the user, where the incoming call screen comprises a caller identification data field for displaying data associated with incoming calls and at least one key label field in which labels for mobile device keys (e.g. send and end keys) are displayed. The area of the caller identification data field is substantially greater than the area of the at least one key label field, enabling more information pertaining to incoming calls to be displayed to the user. In at least one embodiment, this is facilitated by providing user-selectable options for responding to incoming calls in an options menu, which can be accessed by a user but is not initially displayed to the user when an incoming call is first received.

CROSS REFERENCE TO RELATED APPLICATION

This application is a continuation of prior U.S. patent application Ser.No. 11/691,051, filed on Mar. 26, 2007, the entirety of which is herebyincorporated by reference.

TECHNICAL FIELD

Embodiments described herein relate generally to user interfacesprovided by mobile device applications, and more specifically tophone-equipped mobile devices that allow calls to be received by users.

BACKGROUND

Many modern mobile devices are multi-functional. They may be configuredto allow users to engage in both electronic mail (“e-mail”)communications and telephone communications, for example. Additionally,it is common for a user to utilize the mobile device for differentpurposes. For example, a user may operate a single mobile device toengage in communications relating to both business and personal uses.Some phone-equipped mobile devices may be adapted to accommodate anAlternate Line Service (ALS) or similar service. With respect to thesemobile devices, two (or more) phone numbers may be associated with amobile device, with each phone number being associated with a differentcommunication line.

Typically, mobile devices are configured to notify users of an incomingcall by displaying an incoming call screen in which details of the calland a set of options for response are provided. For example, text datacomprising a name and telephone number may be displayed in an upper halfof the incoming call screen, while a list of virtual buttonsrepresenting user-selectable options (e.g. “Answer Call”, “Ignore Call”)may be displayed in a lower half of the incoming call screen.

BRIEF DESCRIPTION OF THE DRAWINGS

For a better understanding of embodiments described herein, and to showmore clearly how they may be carried into effect, reference will now bemade, by way of example, to the accompanying drawings in which:

FIG. 1 is a block diagram of a mobile device in one exampleimplementation;

FIG. 2 is a block diagram of a communication subsystem component of themobile device of FIG. 1;

FIG. 3 is a block diagram of a node of a wireless network;

FIG. 4 is a block diagram illustrating further aspects of the mobiledevice of FIG. 1;

FIG. 5 is a flowchart illustrating steps of a method of providing a userinterface for managing calls received at a mobile device in accordancewith at least one embodiment;

FIG. 6 is an example of a screenshot of a user interface provided to auser in accordance with an example implementation of one embodiment;

FIG. 7A is an example of a screenshot of a user interface provided to auser in accordance with an example implementation of another embodiment;

FIG. 7B is an example of a screenshot of a user interface that displaysdata used to populate the user interface of FIG. 7A; and

FIG. 8 is an example of a screenshot of a user interface provided to auser in accordance with an example implementation of another embodiment.

DETAILED DESCRIPTION

As mobile devices become more functional, the number of user-selectableoptions that can be made available to users for managing incoming callswill increase. Providing the user with all available options forresponding to a call at the time the call is first received can bedifficult to accommodate, particularly in known user interfaces whereincoming call details and identifiers for all available options areinitially displayed simultaneously within a single incoming call screen.Moreover, the amount of data that can be displayed to a user at anygiven time is generally constrained by the limited screen area typicallyavailable on most mobile devices.

In respect of these known user interfaces, as the number of options tobe displayed to a user when a call is first received increases, theremaining area on the incoming call screen for displaying details of theincoming call (e.g. data identifying the caller to the user) woulddecrease. This may be undesirable, as users will typically want toconsider details of the incoming call first in order to determine theuser's course of action (e.g. whether to answer the call or not).Receiving more detailed information on the incoming call may bepreferable to receiving details on all available options for response,particularly if the user typically only selects a small number ofoptions (e.g. answer call, ignore call) in routine use.

Embodiments described herein are generally directed to a system andmethod for providing an improved user interface for receiving calls onphone-equipped mobile devices.

In a broad aspect, there is provided a method of providing a userinterface for managing calls received at a mobile device, the mobiledevice providing access to at least a first communication lineconfigured to receive the calls, the mobile device providing send andend keys, the method comprising the steps of: identifying a phone numberassociated with an incoming call being received at the mobile device;and displaying an incoming call screen on a display to a user of themobile device, the incoming call screen comprising (i) a calleridentification data field for displaying data associated with incomingcalls and (ii) at least one key label field in which first and secondlabels for the send key and end key respectively are displayed; whereinthe area of the caller identification data field is substantiallygreater than the area of the at least one key label field; and whereinan options menu is displayed on the incoming call screen only if adirection to display the options menu is received from the user afterthe incoming call is first received at the mobile device.

In one embodiment, the method of providing a user interface for managingcalls received at a mobile device comprises the steps of: detecting whenthe user provides the direction to display the options menu, displayingthe options menu to the user, detecting when the user selects an optionfrom the options menu, and processing the incoming call in accordancewith the user-selected option.

In one embodiment, the method of providing a user interface for managingcalls received at a mobile device comprises displaying a wireless audiodevice icon.

In another embodiment, the method of providing a user interface formanaging calls received at a mobile device comprises displaying at leastone item of data associated with the incoming call in an area of thecaller identification data field that is substantially centered along atleast one axis of the display.

In another embodiment, the method of providing a user interface formanaging calls received at a mobile device comprises displaying acompany name from a contact entry associated with an incoming call inthe caller identification data field.

In another embodiment, the method of providing a user interface formanaging calls received at a mobile device comprises displaying dataidentifying the communication line on which a call is received in thecaller identification data field.

These and other aspects and features of various embodiments will bedescribed in greater detail below.

Some embodiments described herein make use of a mobile station. A mobilestation is a two-way communication device with advanced datacommunication capabilities having the capability to communicate withother computer systems, and is also referred to herein generally as amobile device. A mobile device may also include the capability for voicecommunications. Depending on the functionality provided by a mobiledevice, it may be referred to as a data messaging device, a two-waypager, a cellular telephone with data messaging capabilities, a wirelessInternet appliance, or a data communication device (with or withouttelephony capabilities). A mobile device communicates with other devicesthrough a network of transceiver stations.

To aid the reader in understanding the structure of a mobile device andhow it communicates with other devices, reference is made to FIGS. 1through 3.

Referring first to FIG. 1, a block diagram of a mobile device in oneexample implementation is shown generally as 100. Mobile device 100comprises a number of components, the controlling component beingmicroprocessor 102. Microprocessor 102 controls the overall operation ofmobile device 100. Communication functions, including data and voicecommunications, are performed through communication subsystem 104.Communication subsystem 104 receives messages from and sends messages toa wireless network 200. In this example implementation of mobile device100, communication subsystem 104 is configured in accordance with theGlobal System for Mobile Communication (GSM) and General Packet RadioServices (GPRS) standards. The GSM/GPRS wireless network is usedworldwide and it is expected that these standards will be supersededeventually by Enhanced Data GSM Environment (EDGE) and Universal MobileTelecommunications Service (UMTS). New standards are still beingdefined, but it is believed that they will have similarities to thenetwork behaviour described herein, and it will also be understood bypersons skilled in the art that the invention is intended to use anyother suitable standards that are developed in the future. The wirelesslink connecting communication subsystem 104 with network 200 representsone or more different Radio Frequency (RF) channels, operating accordingto defined protocols specified for GSM/GPRS communications. With newernetwork protocols, these channels are capable of supporting both circuitswitched voice communications and packet switched data communications.

Although the wireless network associated with mobile device 100 is aGSM/GPRS wireless network in one example implementation of mobile device100, other wireless networks may also be associated with mobile device100 in variant implementations. Different types of wireless networksthat may be employed include, for example, data-centric wirelessnetworks, voice-centric wireless networks, and dual-mode networks thatcan support both voice and data communications over the same physicalbase stations. Combined dual-mode networks include, but are not limitedto, Code Division Multiple Access (CDMA) or CDMA2000 networks, GSM/GPRSnetworks (as mentioned above), and future third-generation (3G) networkslike EDGE and UMTS. Some older examples of data-centric networks includethe Mobitex™ Radio Network and the DataTAC™ Radio Network. Examples ofolder voice-centric data networks include Personal Communication Systems(PCS) networks like GSM and Time Division Multiple Access (TDMA)systems.

Microprocessor 102 also interacts with additional subsystems such as aRandom Access Memory (RAM) 106, flash memory 108, display 110, auxiliaryinput/output (I/O) subsystem 112, serial port 114, keyboard 116, speaker118, microphone 120, short-range communications subsystem 122 and otherdevices 124.

Some of the subsystems of mobile device 100 performcommunication-related functions, whereas other subsystems may provide“resident” or on-device functions. By way of example, display 110 andkeyboard 116 may be used for both communication-related functions, suchas entering a text message for transmission over network 200, anddevice-resident functions such as a calculator or task list. Operatingsystem software used by microprocessor 102 is typically stored in apersistent store such as flash memory 108, which may alternatively be aread-only memory (ROM) or similar storage element (not shown). Thoseskilled in the art will appreciate that the operating system, specificdevice applications, or parts thereof, may be temporarily loaded into avolatile store such as RAM 106.

Mobile device 100 may send and receive communication signals overnetwork 200 after required network registration or activation procedureshave been completed. Network access is associated with a subscriber oruser of a mobile device 100. To identify a subscriber, mobile device 100requires a Subscriber Identity Module or “SIM” card 126 to be insertedin a SIM interface 128 in order to communicate with a network. SIM 126is one type of a conventional “smart card” used to identify a subscriberof mobile device 100 and to personalize the mobile device 100, amongother things. Without SIM 126, mobile device 100 is not fullyoperational for communication with network 200. By inserting SIM 126into SIM interface 128, a subscriber can access all subscribed services.Services could include: web browsing and messaging such as e-mail, voicemail, Short Message Service (SMS), and Multimedia Messaging Services(MMS). More advanced services may include: point of sale, field serviceand sales force automation. SIM 126 includes a processor and memory forstoring information. Once SIM 126 is inserted in SIM interface 128, itis coupled to microprocessor 102. In order to identify the subscriber,SIM 126 contains some user parameters such as an International MobileSubscriber Identity (IMSI). An advantage of using SIM 126 is that asubscriber is not necessarily bound by any single physical mobiledevice. SIM 126 may store additional subscriber information for a mobiledevice as well, including datebook (or calendar) information and recentcall information.

Mobile device 100 is a battery-powered device and includes a batteryinterface 132 for receiving one or more rechargeable batteries 130.Battery interface 132 is coupled to a regulator (not shown), whichassists battery 130 in providing power V+ to mobile device 100. Althoughcurrent technology makes use of a battery, future technologies such asmicro fuel cells may provide the power to mobile device 100.

Microprocessor 102, in addition to its operating system functions,enables execution of software applications on mobile device 100. A setof applications that control basic device operations, including data andvoice communication applications, will normally be installed on mobiledevice 100 during its manufacture. Another application that may beloaded onto mobile device 100 would be a personal information manager(PIM). A PIM has functionality to organize and manage data items ofinterest to a subscriber, such as, but not limited to, e-mail, calendarevents, voice mails, appointments, and task items. A PIM application hasthe ability to send and receive data items via wireless network 200. PIMdata items may be seamlessly integrated, synchronized, and updated viawireless network 200 with the mobile device subscriber's correspondingdata items stored and/or associated with a host computer system. Thisfunctionality creates a mirrored host computer on mobile device 100 withrespect to such items. This can be particularly advantageous where thehost computer system is the mobile device subscriber's office computersystem.

Additional applications may also be loaded onto mobile device 100through network 200, auxiliary I/O subsystem 112, serial port 114,short-range communications subsystem 122, or any other suitablesubsystem 124. This flexibility in application installation increasesthe functionality of mobile device 100 and may provide enhancedon-device functions, communication-related functions, or both. Forexample, secure communication applications may enable electroniccommerce functions and other such financial transactions to be performedusing mobile device 100.

Serial port 114 enables a subscriber to set preferences through anexternal device or software application and extends the capabilities ofmobile device 100 by providing for information or software downloads tomobile device 100 other than through a wireless communication network.The alternate download path may, for example, be used to load anencryption key onto mobile device 100 through a direct and thus reliableand trusted connection to provide secure device communication.

Short-range communications subsystem 122 provides for communicationbetween mobile device 100 and different systems or devices, without theuse of network 200. For example, subsystem 122 may include an infrareddevice and associated circuits and components for short-rangecommunication. Examples of short range communication would includestandards developed by the Infrared Data Association (IrDA), Bluetooth,and the 802.11 family of standards developed by IEEE.

In use, a received signal such as a text message, an e-mail message, orweb page download will be processed by communication subsystem 104 andinput to microprocessor 102. Microprocessor 102 will then process thereceived signal for output to display 110 or alternatively to auxiliaryI/O subsystem 112. A subscriber may also compose data items, such ase-mail messages, for example, using keyboard 116 in conjunction withdisplay 110 and possibly auxiliary I/O subsystem 112. Auxiliarysubsystem 112 may include devices such as: a touch screen, mouse, trackball, infrared fingerprint detector, or a roller wheel with dynamicbutton pressing capability. Keyboard 116 is an alphanumeric keyboardand/or telephone-type keypad. A composed item may be transmitted overnetwork 200 through communication subsystem 104.

For voice communications, the overall operation of mobile device 100 issubstantially similar, except that the received signals would be outputto speaker 118, and signals for transmission would be generated bymicrophone 120. Alternative voice or audio I/O subsystems, such as avoice message recording subsystem, may also be implemented on mobiledevice 100. Although voice or audio signal output is accomplishedprimarily through speaker 118, display 110 may also be used to provideadditional information such as the identity of a calling party, durationof a voice call, or other voice call related information.

Referring now to FIG. 2, a block diagram of the communication subsystemcomponent 104 of FIG. 1 is shown. Communication subsystem 104 comprisesa receiver 150, a transmitter 152, one or more embedded or internalantenna elements 154, 156, Local Oscillators (LOs) 158, and a processingmodule such as a Digital Signal Processor (DSP) 160.

The particular design of communication subsystem 104 is dependent uponthe network 200 in which mobile device 100 is intended to operate, thusit should be understood that the design illustrated in FIG. 2 servesonly as one example. Signals received by antenna 154 through network 200are input to receiver 150, which may perform such common receiverfunctions as signal amplification, frequency down conversion, filtering,channel selection, and analog-to-digital (ND) conversion. ND conversionof a received signal allows more complex communication functions such asdemodulation and decoding to be performed in DSP 160. In a similarmanner, signals to be transmitted are processed, including modulationand encoding, by DSP 160. These DSP-processed signals are input totransmitter 152 for digital-to-analog (D/A) conversion, frequency upconversion, filtering, amplification and transmission over network 200via antenna 156. DSP 160 not only processes communication signals, butalso provides for receiver and transmitter control. For example, thegains applied to communication signals in receiver 150 and transmitter152 may be adaptively controlled through automatic gain controlalgorithms implemented in DSP 160.

The wireless link between mobile device 100 and a network 200 maycontain one or more different channels, typically different RF channels,and associated protocols used between mobile device 100 and network 200.A RF channel is a limited resource that must be conserved, typically dueto limits in overall bandwidth and limited battery power of mobiledevice 100.

When mobile device 100 is fully operational, transmitter 152 istypically keyed or turned on only when it is sending to network 200 andis otherwise turned off to conserve resources. Similarly, receiver 150is periodically turned off to conserve power until it is needed toreceive signals or information (if at all) during designated timeperiods.

Referring now to FIG. 3, a block diagram of a node of a wireless networkis shown as 202. In practice, network 200 comprises one or more nodes202. Mobile device 100 communicates with a node 202 within wirelessnetwork 200. In the example implementation of FIG. 3, node 202 isconfigured in accordance with General Packet Radio Service (GPRS) andGlobal Systems for Mobile (GSM) technologies. Node 202 includes a basestation controller (BSC) 204 with an associated tower station 206, aPacket Control Unit (PCU) 208 added for GPRS support in GSM, a MobileSwitching Center (MSC) 210, a Home Location Register (HLR) 212, aVisitor Location Registry (VLR) 214, a Serving GPRS Support Node (SGSN)216, a Gateway GPRS Support Node (GGSN) 218, and a Dynamic HostConfiguration Protocol (DHCP) 220. This list of components is not meantto be an exhaustive list of the components of every node 202 within aGSM/GPRS network, but rather a list of components that are commonly usedin communications through network 200.

In a GSM network, MSC 210 is coupled to BSC 204 and to a landlinenetwork, such as a Public Switched Telephone Network (PSTN) 222 tosatisfy circuit switched requirements. The connection through PCU 208,SGSN 216 and GGSN 218 to the public or private network (Internet) 224(also referred to herein generally as a shared network infrastructure)represents the data path for GPRS capable mobile devices. In a GSMnetwork extended with GPRS capabilities, BSC 204 also contains a PacketControl Unit (PCU) 208 that connects to SGSN 216 to controlsegmentation, radio channel allocation and to satisfy packet switchedrequirements. To track mobile device location and availability for bothcircuit switched and packet switched management, HLR 212 is sharedbetween MSC 210 and SGSN 216. Access to VLR 214 is controlled by MSC210.

Station 206 is a fixed transceiver station. Station 206 and BSC 204together form the fixed transceiver equipment. The fixed transceiverequipment provides wireless network coverage for a particular coveragearea commonly referred to as a “cell”. The fixed transceiver equipmenttransmits communication signals to and receives communication signalsfrom mobile devices within its cell via station 206. The fixedtransceiver equipment normally performs such functions as modulation andpossibly encoding and/or encryption of signals to be transmitted to themobile device in accordance with particular, usually predetermined,communication protocols and parameters, under control of its controller.The fixed transceiver equipment similarly demodulates and possiblydecodes and decrypts, if necessary, any communication signals receivedfrom mobile device 100 within its cell. Communication protocols andparameters may vary between different nodes. For example, one node mayemploy a different modulation scheme and operate at differentfrequencies than other nodes.

For all mobile devices 100 registered with a specific network, permanentconfiguration data such as a user profile is stored in HLR 212. HLR 212also contains location information for each registered mobile device andcan be queried to determine the current location of a mobile device. MSC210 is responsible for a group of location areas and stores the data ofthe mobile devices currently in its area of responsibility in VLR 214.Further VLR 214 also contains information on mobile devices that arevisiting other networks. The information in VLR 214 includes part of thepermanent mobile device data transmitted from HLR 212 to VLR 214 forfaster access. By moving additional information from a remote HLR 212node to VLR 214, the amount of traffic between these nodes can bereduced so that voice and data services can be provided with fasterresponse times and at the same time requiring less use of computingresources.

SGSN 216 and GGSN 218 are elements added for GPRS support; namely packetswitched data support, within GSM. SGSN 216 and MSC 210 have similarresponsibilities within wireless network 200 by keeping track of thelocation of each mobile device 100. SGSN 216 also performs securityfunctions and access control for data traffic on network 200. GGSN 218provides internetworking connections with external packet switchednetworks and connects to one or more SGSNs 216 via an Internet Protocol(IP) backbone network operated within the network 200. During normaloperations, a given mobile device 100 must perform a “GPRS Attach” toacquire an IP address and to access data services. This requirement isnot present in circuit switched voice channels as Integrated ServicesDigital Network (ISDN) addresses are used for routing incoming andoutgoing calls. Currently, all GPRS capable networks use private,dynamically assigned IP addresses, thus requiring a DHCP server 220connected to the GGSN 218. There are many mechanisms for dynamic IPassignment, including using a combination of a Remote AuthenticationDial-In User Service (RADIUS) server and DHCP server. Once the GPRSAttach is complete, a logical connection is established from a mobiledevice 100, through PCU 208, and SGSN 216 to an Access Point Node (APN)within GGSN 218. The APN represents a logical end of an IP tunnel thatcan either access direct Internet compatible services or private networkconnections. The APN also represents a security mechanism for network200, insofar as each mobile device 100 must be assigned to one or moreAPNs and mobile devices 100 cannot exchange data without firstperforming a GPRS Attach to an APN that it has been authorized to use.The APN may be considered to be similar to an Internet domain name suchas “myconnection.wireless.com”.

Once the GPRS Attach is complete, a tunnel is created and all traffic isexchanged within standard IP packets using any protocol that can besupported in IP packets. This includes tunneling methods such as IP overIP as in the case with some IPSecurity (IPsec) connections used withVirtual Private Networks (VPN). These tunnels are also referred to asPacket Data Protocol (PDP) Contexts and there are a limited number ofthese available in the network 200. To maximize use of the PDP Contexts,network 200 will run an idle timer for each PDP Context to determine ifthere is a lack of activity. When a mobile device 100 is not using itsPDP Context, the PDP Context can be de-allocated and the IP addressreturned to the IP address pool managed by DHCP server 220.

Referring now to FIG. 4, a block diagram illustrating further aspects ofmobile device 100 of FIG. 1 is shown generally as 300. As noted earlierwith reference to FIG. 1, microprocessor 102, in addition to itsoperating system functions, enables execution of software applicationson mobile device 100. A set of applications that control basic deviceoperations, including data and voice communication applications, willnormally be installed on mobile device 100 during its manufacture.Operating system software and other software applications are typicallystored in a persistent store (e.g. flash memory 106) or other store, onmobile device 100 or on a device coupled thereto. It will be understoodthat the operating system, software applications or parts thereof, maybe temporarily loaded in a volatile store such as RAM 106. Otherinstructions and/or data received by the mobile device 100 and subjectto processing may also be temporarily stored in RAM 106.

Software applications that are loaded or stored on mobile device 100 maybe implemented as functional components or modules 310. Modules 310interact with various components of mobile device 100. For instance, asshown by way of example in FIG. 4, modules 310 may interact withcommunication subsystem 104, RAM 106, flash memory 108, display 110,auxiliary I/O device(s) 112, and keyboard 116. Modules 310 may comprise,for example, an address book module 312, a messaging module 314 (e.g.for e-mail and/or SMS or MMS messaging), and a phone application module316.

Address book (also referred to as “contact book”) module 312 isgenerally configured to allow contact information (e.g. contact entriescomprising individual contact and company names, telephone numbers,messaging addresses, pictures and other information) to be stored andmanaged.

Messaging module 314 facilitates the sending and receiving of electronicmessages over a wireless network 200 and/or other network.

Phone application module 316 is generally configured to facilitate voicecommunication between the user and other parties, including theplacement of outgoing calls by the user and the reception of incomingcalls on the mobile device 100.

Calls may be placed and received on a communication line specificallyconfigured for voice communications. In certain embodiments, calls mayalternatively or additionally be placed and received on other types ofcommunication lines, including a communication line generally configuredfor data communications, or a communication line configured for bothvoice and data communications, for example. For example, mobile device100 may be configured to provide Voice over IP (VoIP) and/or video phonefunctionality.

Some mobile devices are configured to provide access to multiple (i.e.two or more) communication lines on which incoming calls may bereceived. Typically, these mobile devices will also be configured toallow outgoing calls to be initiated by the user over the samecommunication lines. Each of the multiple communication lines may have adifferent telephone number associated therewith. For example, a user mayhave a business phone number and a different personal phone number.Referring again to FIG. 4, a line selection module (e.g. alternate lineservice (ALS) module) 318 is provided to facilitate selection of thecommunication line to be used by phone application module 316 forplacing an outgoing call, for example. The line selection module 318 isconfigured to select a communication line to be used by phoneapplication module 316, based upon line selection data stored on mobiledevice 100 (e.g. configuration settings that define a defaultcommunication line), and/or based upon input received by the user. Itwill be understood that the functionality of line selection module 318may be provided or otherwise integrated with phone application module316 or with a different module on mobile device 100.

When an incoming call is received at the mobile device, an incoming callscreen is typically displayed, in which details of the call and a set ofoptions for response are provided. As users will likely want to considerdetails of the incoming call first in order to determine the user'scourse of action (e.g. whether to answer the call or not), it may bedesirable to provide more detailed information on the incoming call to auser at the time the call is first received. However, the amount of suchcaller identification information that may be provided to users is oftenrestricted in known user interfaces, as a substantial portion of theincoming call screen is typically also used to provide details on allthe available options for response at the time the call is firstreceived, and the amount of screen area provided by a mobile device isgenerally limited.

Embodiments described herein are generally directed to a system andmethod for providing an improved user interface for receiving calls onphone-equipped mobile devices.

More specifically, embodiments described herein relate generally to auser interface that provides an incoming call screen to the user, wherethe incoming call screen comprises a caller identification data fieldfor displaying data associated with incoming calls and at least one keylabel field in which labels for mobile device keys (e.g. send and endkeys) are displayed.

In one embodiment, the combined areas of the caller identification datafield and the at least one key label field substantially occupies theentire visible area of the display of the mobile device.

In example embodiments, the area of the caller identification data fieldis substantially greater than the area of the at least one key labelfield, enabling more information pertaining to incoming calls to bedisplayed to the user when a call is first received at the mobiledevice.

In accordance with at least one embodiment, this is facilitated byproviding user-selectable options for responding to incoming calls in anoptions menu, which can be accessed by a user but is not initiallydisplayed to the user when an incoming call is first received. Theoptions menu is displayed on the incoming call screen only if adirection to display the options menu is received from the user afterthe incoming call is first received at the mobile device.

In one embodiment, the options menu is accessible when the userdepresses a menu key or other pre-programmed key on the mobile deviceafter the incoming call is first received at the mobile device. Anoptions menu identifier (e.g. “More”) may be displayed in a key labelfield on the display (e.g. near the corresponding menu key or otherpre-programmed key, or with an additional identifier that otherwiseindicates the corresponding key) to indicate the key that must bepressed by the user to direct that the options menu be displayed.

In one embodiment, labels (e.g. phone icons, text identifiers) areprovided over the send and end keys provided on the mobile device as“hints” to indicate the function of these keys. Each of these labels isdisplayed in a key label field on the display (e.g. near the respectivekey, or with an additional identifier that otherwise indicates therespective key). Accordingly, virtual buttons to identify the sameactions associated with these keys need not be displayed in the calleridentification data field when a call is first received at the mobiledevice.

In one embodiment, a wireless audio device icon is displayed with thelabel for the send key to indicate that audio signals for the call willbe transmitted to an auxiliary audio device rather than to an integratedspeaker on the mobile device. The auxiliary audio device may be, forexample, a wireless audio device (e.g. a Bluetooth™ headset or earpiece,a remote speaker).

In one embodiment, at least some caller identification data is displayedin an area of the caller identification data field that is substantiallycentered along at least one axis of the display. For example, certaincaller identification data (e.g. name of caller, phone number, picture,and/or company name) can be displayed in an area centered along avertical axis on the display.

In one embodiment, caller identification data displayed in the calleridentification data field comprises data (e.g. company name, picture)from a contact entry associated with an incoming call on the mobiledevice.

In one embodiment, where the mobile device is configured to provideaccess to multiple communication lines configured to receive calls,caller identification data displayed in the caller identification datafield comprises data identifying the communication line on which a callis received at the mobile device.

Further features of the above-mentioned embodiments and of otherembodiments will be apparent from the description that follows and theappended Figures.

Referring now to FIG. 5, a flowchart illustrating steps of a method ofproviding a user interface for managing calls received at a mobiledevice in accordance with at least one embodiment is shown generally as400. Additional details of some of the features described below inrespect of the steps of method 400 may be described earlier in thepresent specification.

In one embodiment, the steps of method 400 are performed at the mobiledevice by an application (e.g. phone application module 316 of FIG. 4)that executes and resides on the mobile device (e.g. mobile device 100of FIG. 1). The application need not be a stand-alone application, andthe functionality described herein may be implemented in one or moreapplications executing and residing on the mobile device.

At step 410, a call for a user of the mobile device (“incoming call”) isreceived on a communication line accessible at the mobile device. Thecall may be received over a communication line specifically configuredfor voice communications, for data communications, or for both,depending on the implementation.

At step 420, the phone number associated with the incoming call isidentified. The phone number may subsequently be displayed to the user(e.g. at step 440). It may also be used, for example, to determine theidentity of the caller and to associate the incoming call with a contactentry in the user's address book (e.g. at steps 430 and 432).

At step 430, a determination is made as to whether a contact entry inthe user's address book is associated with the incoming call. This maybe performed by attempting to match the phone number identified at step420 with a corresponding data item in a contact entry in the user'saddress book. If a match is found, then at step 432, further data itemsfrom the associated contact entry (e.g. individual name, company name,picture) may be retrieved for subsequent display (at step 440) in acaller identification data field of an incoming call screen. If no matchis found, then the flow of method steps proceeds directly to step 440.

At step 440, an incoming call screen is displayed to the user on adisplay (e.g. display 110 of FIG. 1) of the mobile device. The incomingcall screen informs the user that a call is being received at the mobiledevice, and presents the user with options for response. The incomingcall screen is divided into a caller identification data field fordisplaying data associated with the incoming call, and at least one keylabel field in which labels can be displayed to inform the user of atleast some actions that may be taken by the user by depressing certainkeys provided on the mobile device. Further user interface features inrespect of the incoming call screen that may be implemented in variousembodiments are illustrated with reference to the example screenshots ofFIGS. 6 through 8.

In use, when a call is first received at the mobile device, the userwill typically look at the displayed incoming call screen to see who iscalling. Accordingly, it may be preferable to have a substantial portionof the incoming call screen dedicated to providing the information thatidentifies the caller when the call is first received. The user willthen need to decide what action should be taken with respect to theincoming call. It is expected that the user will often decide to simplyanswer or ignore the call by depressing the send or the end key withoutthe need to consider alternative response options.

Accordingly, a comprehensive list of available options is not providedon the incoming call screen when a call is first received. Thispotentially allows the area of the caller identification data field tooccupy a relatively large proportion of the display. The area of the atleast one key label field can be kept relatively small (e.g. occupyingabout 10% of the display). This may allow, for example, a greater numberof caller identification data items to be displayed, and/or greaterflexibility in laying out caller identification data items within thecaller identification data field so that they might be more easily readby the user.

At step 450, a selection of a mobile device key made by the user (e.g.the user has depressed the key) is detected. The selected key may be asend key (e.g. an “Answer” key), an end key (e.g. an “Ignore” key), amenu key, or some other pre-programmed key.

At step 460, it is determined whether the selection made at step 450 isto result in the display of an options menu. For example, if a menu keyis pressed, an options menu will be displayed to the user.

In an example use, the user directs that an option menu be displayedwhen the user wishes to consider additional options for responding tothe incoming call (e.g. “advanced options”) other than the basic answerand ignore functions available by pressing the send or end keys. As aresult, the information identifying the caller as displayed in thecaller identification data field need not be obscured unless the userspecifically wishes to consider the additional options.

The menu key may or may not be identified by an options menu identifierdisplayed in association with that menu key. Where the menu key is to beidentified by an options menu identifier, the options menu identifier isdisplayed in a key label field in this embodiment.

On the other hand, if the send key or the end key is pressed, anotheraction (e.g. answering the call, ignoring the call) will be performedwithout requiring the options menu to be displayed. Furthermore, wherethe user is already engaged in a different call when the incoming callis received, a default answering function (e.g. answer the incoming calland hold the other call) will be performed when the send key is pressed.

An options menu provides the user with options for responding to thecall currently being received at the mobile device. For example, wherethe user is already engaged in a different call when the incoming callis received, the user may be provided with the following options: answerthe incoming call and hold the other call, answer the incoming call anddrop the other call, or ignore the incoming call and continue with theother call.

Other options and/or different options may be provided in variantembodiments. For example, an option may be provided to place theincoming call on hold, until the user makes a further selection toanswer or drop the call. As a further example, an option may be providedto forward the incoming call to another telephone number (e.g. alandline telephone). As a further example, an option may be provided toredirect audio output to a specified device (e.g. a wireless headset, aremote speaker).

If it is determined at step 460 that the selection requires an optionmenu to be displayed, the option menu is displayed at step 462, and aselection of an option by the user is detected at step 464. Otherwise,the flow of method steps proceeds directly to step 470.

At step 470, the incoming call is processed according to the selectionof the mobile device key by the user as detected at step 450, or theselection of an option from the options menu by the user as detected atstep 464, depending on the determination made at step 460. For example,the incoming call may be answered or ignored at this step, in knownmanner. If the incoming call has been received while the user is engagedin a different call, the different call may be put on hold or dropped atthis step for example, in known manner.

If the user engages in the incoming call by answering the call, the callwill continue until it is terminated (e.g. by the user or by the caller)at step 480.

A further call may be received at the mobile device while the user isalready engaged in a call if, for example, the mobile device isconfigured to provide “call waiting” functionality. In this manner, afurther iteration of method 400 may be performed before the previousiteration has terminated. In that case, the steps of a new instance ofmethod 400 may be concurrently performed as shown by the dotted arrow inFIG. 5.

Referring now to FIG. 6, a screenshot of a user interface provided to auser in accordance with an example implementation of one embodiment isshown generally as 500.

In FIG. 6, screenshot 500 illustrates a user interface displayed in adisplay 110 of a mobile device 100, namely for an incoming call screen510 used to inform the user of calls being received at mobile device100. Mobile device 100 provides an integrated speaker 118, a visualalert indicator 512, a send key 514, an end key 516 (end key 516 is alsoused as a power-on key in this example implementation), a track ball518, a menu key 520, and an escape key 522.

While send key 514, end key 516, menu key 520 and escape key 522 areshown as physical keys provided on the mobile device in this example, itwill be understood by persons skilled in the art that some mobiledevices may provide one or more of these keys as virtual keys on atouch-sensitive screen.

Incoming call screen 510 is divided into a caller identification datafield 530 and a key label field 532. In this example, the combined areasof caller identification data field 530 and key label field 532 occupythe entire area of display 110. Moreover, the area of calleridentification data field 530 is much greater than the area of key labelfield 532, allowing for greater flexibility in the layout of calleridentification data and potentially making displayed calleridentification data easier to read. In this example, key label field 532is illustrated as one contiguous field, although more than one separatekey label field may be displayed on incoming call screen 510 in variantembodiments.

In this example, the following items are displayed in calleridentification data field 530:

-   -   a background image is shown within caller identification data        field 530;    -   a data transmission indicator 540 in the upper-right hand corner        of display 110;    -   a “waiting call” indicator 542 centrally justified        (horizontally) near the top of display 110, indicating that the        incoming call is awaiting user consideration while the user is        engaged in a different call;    -   the name of the caller 544 associated with the current incoming        call, the phone number 546 associated with the current incoming        call, and a picture 548 associated with the caller, shown        substantially centered (vertically) in the display 110.

In this example, key label field 532 is confined to a narrow section ofdisplay 110, at an end of display 110 nearest the send key 514 and endkey 516 provided by mobile device 100. A first label is displayed in anarea on display 110 within key label field 532 close to and above sendkey 514. The first label comprises a text identifier “Answer” 550 and ananswer icon 552. In this example, a Bluetooth™ headset has beenactivated for use, and accordingly, a wireless audio device icon (e.g. aBluetooth™ symbol) 554 is also shown with the first label. A secondlabel is displayed in an area on display 110 within key label field 532close to and above end key 516. The second label comprises a textidentifier “Ignore” 556 and an ignore icon 558. An options menuidentifier 560 is also displayed within key label field 532. In thisexample, options menu identifier 560 is displayed in an area close toand above track ball 518, and includes a white circle to suggest thatthe track ball 518 can be depressed to direct that an options menu bedisplayed. However, a direction to display to the options menu may beprovided by depressing a different key (e.g. menu key 520) depending onthe implementation. The options menu may also be displayed after a userdepresses a key such as the menu key 520 even if an options menuidentifier 560 has not been displayed within key label field 532.

Referring now to FIG. 7A, a screenshot of a user interface provided to auser in accordance with an example implementation of another embodimentis shown generally as 600.

Screenshot 600 illustrates a number of similar elements as shown in FIG.6. Similar reference numerals are used to refer to similar elements, andreference may be made to the description in respect of screenshot 500 ofFIG. 6 for further details on those elements that also appear inscreenshot 600.

In FIG. 7A, an “incoming call” indicator 602 is displayed, showncentrally justified (horizontally) near the top of display 110 in thisexample, indicating that a call is being received at mobile device 100.In this embodiment, options menu identifier 560 (FIG. 6) is not shown,as the user is not currently engaged in a different call. However, asnoted earlier, an option menu may still be accessible (e.g. by pressingmenu key 520) even if options menu identifier 560 is not shown. It willalso be understood that an options menu identifier may be shown even ifthe user is not currently engaged in a different call.

A company name 604, along with name of the caller 544, phone number 546,and picture 548 is displayed in caller identification data field 530.After identifying phone number 546 when the call is received, a contactentry associated with the incoming call is determined by matching phonenumber 546 to a corresponding data item in a contact entry stored on themobile device. Once the contact entry associated with the incoming callis determined, data items in the contact entry such as name of thecaller 544, picture 548, and/or company name 604 can be retrieved fordisplay on the caller identification data field 530 of incoming callscreen 510.

To further illustrate the foregoing features, reference is made to FIG.7B showing a screenshot 610 in display 110, where the user has directedthe associated contact entry 612 to be displayed. FIG. 7B is an exampleof a screenshot of a user interface that displays contact entry dataused to populate the user interface of FIG. 7A.

Contact entry 612 comprises a contact name 544, a company name 604, anda title 614 within a primary contact details field 616. Contact entry612 further comprises one or more pictures 548 associated with thecontact. Contact entry 612 further comprises an e-mail address 618, anda second “Work” phone number 620 in addition to “Home” phone number 546,within one or more contact details fields 622. Although not shown inFIG. 7A, an identification of the caller's line (e.g. “Work”, “Home”)can also be determined for display in caller identification data field530.

Further phone numbers or other contact details may be provided withincontact details field 622. The existence of additional contact detailsis indicated in this example by icon 624.

As previously noted, when a phone number for an incoming call isidentified, it can be matched to a phone number in the contact detailsfield 622 of contact entries stored on mobile device 100 to determinethe associated contact entry (if one exists). Data from the associatedcontact entry can then be retrieved for display.

Referring now to FIG. 8, a screenshot of a user interface provided to auser in accordance with an example implementation of another embodimentis shown generally as 700.

Screenshot 700 illustrates a number of similar elements as shown inFIGS. 6, 7A and 7B. Similar reference numerals are used to refer tosimilar elements, and reference may be made to the description inrespect of the corresponding screenshots of FIGS. 6, 7A and 7B forfurther details on those elements that also appear in screenshot 700.

In this example, mobile device 100 provides access to multiplecommunication lines. Communication line identifier 702 is displayed toindicate that the incoming call is being received on the user's“Business” line. The “waiting call” indicator 542 also indicates that acall is being received while the user is already engaged in a differentcall.

In this example, an options menu 704 is displayed. Options menu 704 maybe displayed in response to the user pressing menu key 520 or track ball518 for example, prompting the user for further direction on how tohandle the incoming call and the other call that the user is engaged in.Through options menu 704, the user is provided with a first option 706to answer the incoming call and hold the other call, a second option 708to answer the incoming call and drop the other call, and a third option710 to ignore the incoming call and continue with the other call. Ananswer icon 552 and ignore icon 558 can also be displayed in associationwith the options provided in options menu 704 to suggest that the usercan also select the corresponding option 706 or 710 by pressing send key514 or end key 516 respectively. Other options not shown in this examplemay be provided in options menu 704.

It will be understood by persons skilled in the art that the features ofthe user interfaces illustrated with reference to the examplescreenshots described herein are provided by way of example only. Itwill be understood by persons skilled in the art that variations arepossible in variant implementations and embodiments.

It is noted that although some of the features of embodiments describedherein may have been illustrated in combination in the examples of FIGS.6 through 8 for ease of exposition, this is not to suggest that suchfeatures may only exist in such combinations. It will be understood bypersons skilled in the art that certain features can be implementedindependently of other features, and in different combinations invariant embodiments.

The steps of a method of providing a user interface for managing callsreceived at a mobile device in accordance with any of the embodimentsdescribed herein may be provided as executable software instructionsstored on computer-readable media, which may include transmission-typemedia.

The invention has been described with regard to a number of embodiments.However, it will be understood by persons skilled in the art that othervariants and modifications may be made without departing from the scopeof the invention as defined in the claims appended hereto.

1. A method of providing a user interface for managing calls received ata mobile device, the mobile device providing access to at least a firstcommunication line configured to receive the calls, the methodcomprising: displaying an incoming call screen on a display of themobile device in response to an incoming call received at the mobiledevice, the incoming call screen comprising a caller identification datafield for displaying data associated with the incoming call; wherein anoptions menu comprising user-selectable options for responding to theincoming call is displayed on the incoming call screen if a direction todisplay the options menu is received at the mobile device after theincoming call is received at the mobile device; and wherein a label isdisplayed in at least one key label field in the incoming call screen ifthe incoming call is received at the mobile device while the mobiledevice is engaged in a different call but the label is not displayed ifthe incoming call is received at the mobile device while the mobiledevice is not engaged in the different call, the label comprising anoptions menu identifier associated with the options menu.
 2. The methodof claim 1, wherein an area of the caller identification data field andan area of the at least one key label field, in combination, occupies anentire visible area on the display of the mobile device.
 3. The methodof claim 1, wherein the at least one key label field occupies 10% of anarea of the display.
 4. The method of claim 1, wherein at least oneadditional key label field is displayed proximate send and end keys ofthe mobile device, such that one additional label is displayed in anarea of the display adjacent to the send key, and one other additionallabel is displayed in an area of the display adjacent to the end key. 5.The method of claim 4, wherein the one additional label comprises ananswer icon and a corresponding text identifier, and wherein the otheradditional label comprises an ignore icon and a corresponding textidentifier.
 6. The method of claim 4, wherein the one additional labelcomprises a wireless audio device icon.
 7. The method of claim 1,further comprising: detecting when the direction to display the optionsmenu is received, displaying the options menu in the user interface,detecting when an option from the options menu is user-selected, andprocessing the incoming call in accordance with the user-selectedoption.
 8. The method of claim 1, wherein at least one item of dataassociated with the incoming call is displayed in an area of the calleridentification data field that is centered along at least one axis ofthe display.
 9. The method of claim 1, further comprising: determining acontact entry associated with the incoming call on the mobile device bymatching the phone number associated with the incoming call to a dataitem in the contact entry, and displaying at least one item from thecontact entry in the caller identification data field.
 10. The method ofclaim 9, wherein the at least one item from the contact entry displayedin the caller identification data field comprises a company name. 11.The method of claim 9, wherein the contact entry associated with theincoming call is stored in an address book on the mobile device.
 12. Themethod of claim 1, wherein the mobile device provides access to aplurality of communication lines configured to receive calls, andwherein data identifying the communication line on which the incomingcall is received is displayed in the caller identification data field.13. A non-volatile computer-readable storage medium comprisinginstructions executable on a processor of the mobile device forimplementing a method of providing a user interface for managing callsreceived at a mobile device, the mobile device providing access to atleast a first communication line configured to receive the calls, themethod comprising: displaying an incoming call screen on a display ofthe mobile device in response to an incoming call received at the mobiledevice, the incoming call screen comprising a caller identification datafield for displaying data associated with the incoming call; wherein anoptions menu comprising user-selectable options for responding to theincoming call is displayed on the incoming call screen if a direction todisplay the options menu is received at the mobile device after theincoming call is received at the mobile device; and wherein a label isdisplayed in at least one key label field in the incoming call screen ifthe incoming call is received at the mobile device while the mobiledevice is engaged in a different call but the label is not displayed ifthe incoming call is received at the mobile device while the mobiledevice is not engaged in the different call, the label comprising anoptions menu identifier associated with the options menu.
 14. A mobiledevice on which a user interface for managing calls received at themobile device is provided, the mobile device providing access to atleast a first communication line configured to receive the calls, themobile device comprising a processor, a display, and at least one inputdevice, wherein the processor is configured to: display an incoming callscreen on a display of the mobile device in response to an incoming callreceived at the mobile device, the incoming call screen comprising acaller identification data field for displaying data associated with theincoming call; wherein an options menu comprising user-selectableoptions for responding to the incoming call is displayed on the incomingcall screen if a direction to display the options menu is received atthe mobile device after the incoming call is received at the mobiledevice; and wherein a label is displayed in at least one key label fieldin the incoming call screen if the incoming call is received at themobile device while the mobile device is engaged in a different call butthe label is not displayed if the incoming call is received at themobile device while the mobile device is not engaged in the differentcall, the label comprising an options menu identifier associated withthe options menu.
 15. The device of claim 14, wherein an area of thecaller identification data field and an area of the at least one keylabel field, in combination, occupies an entire visible area on thedisplay of the mobile device.
 16. The device of claim 14, wherein the atleast one key label field occupies 10% of an area of the display. 17.The device of claim 14, wherein at least one additional key label fieldis displayed proximate send and end keys of the mobile device, such thatone additional label is displayed in an area of the display adjacent tothe send key, and one other additional label is displayed in an area ofthe display adjacent to the end key.
 18. The device of claim 17, whereinthe one additional label comprises an answer icon and a correspondingtext identifier, and wherein the other additional label comprises anignore icon and a corresponding text identifier.
 19. The device of claim17, wherein the one additional label comprises a wireless audio deviceicon.
 20. The device of claim 14, wherein the processor is furtherconfigured to: detect when the direction to display the options menu isreceived, display the options menu in the user interface, detect when anoption from the options menu is user-selected, and process the incomingcall in accordance with the user-selected option.
 21. The device ofclaim 14, wherein at least one item of data associated with the incomingcall is displayed in an area of the caller identification data fieldthat is centered along at least one axis of the display.
 22. The deviceof claim 14, wherein the processor is further configured to: determine acontact entry associated with the incoming call on the mobile device bymatching the phone number associated with the incoming call to a dataitem in the contact entry, and display at least one item from thecontact entry in the caller identification data field.
 23. The device ofclaim 22, wherein the at least one item from the contact entry displayedin the caller identification data field comprises a company name. 24.The device of claim 22, wherein the contact entry associated with theincoming call is stored in an address book on the mobile device.
 25. Thedevice of claim 14, wherein the mobile device provides access to aplurality of communication lines configured to receive calls, andwherein data identifying the communication line on which the incomingcall is received is displayed in the caller identification data field.